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WIRELESS INTERNET GATEWAY 



BACKGROUND OF THE INVENTION 

1 . Field of the Invention 

This invention relates generally to wireless carriers, Internet 
service providers (ISPs), and information content delivery services/ 
providers. More particularly, it relates to wireless telecommunications and 
wireless portals for routing messages from mobile devices to Internet 
destinations. 

2. Background of Related Art 

Short Message Service Centers (SMSCs) deliver short 
messages through a wireless network. Typically they operate on highly 
valuable server platforms that are protected deep within a wireless 
carrier's network, and communicate via specialized protocols. 

Fig. 11 shows a conventional gateway providing Internet 
access to a wireless network through a short message service center 
(SMSC). 

In particular, as shown In Fig. 11, a gateway 900 translates 
between HTTP protocol messages from the Internet 190 and SMPP 
protocol messages to wireless devices in a wireless network 130 via an 
SMSC 120. 

The gateway 900 provides a portal between wireless 
networks and the Internet 190. However, conventional portals between 
wireless networks and the Internet generally utilize either a proprietary 
operating system, or are developed to operate on a single operating 
system, e.g., WINDOWS NT™ or SOLARIS™. Moreover, conventional 
gateway 900 architecture provides a communication path between fixed 
protocol types, e.g., between HTTP protocol messages and SMPP 
protocol messages. Separate gateway application programming 
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interfaces (APIs) are developed to communicate with other protocol types. 
For instance, to allow communications between an application server on 
the Internet using HTTP protocol messages and a paging terminal using 
TNPP protocol messages, a new gateway API must be developed from 
5 point-to-point from the HTTP interface to the TNPP interface. This 
presents a tremendous amount of development work necessary to 
support new network elements, particularly wireless network elements. 

There is thus a need for a more flexible gateway architecture 
and method which provides interface capability without the need for the 
10 total redevelopment of separate gateways to support different types of 
message protocols. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Features and advantages of the present invention will 
15 become apparent to those skilled in the art from the following description 
with reference to the drawings, in which: 

Fig. 1 shows exemplary connectivity for a wireless Internet 
gateway, in accordance with the principles of the present invention. 

Fig. 2 shows an exemplary application programming 
20 interface (API) of a wireless Internet gateway including a short message 
queuing mechanism and abstracted generic destination interface, in 
accordance with the principles of the present invention. 

Fig. 3 shows the inclusion of an SNMP manager in a 
wireless Internet gateway and direct communication between wireless 
25 devices and application sen/ers, in accordance with the principles of the 
present invention. 

Fig. 4 shows exemplary log and configuration files utilized by 
a wireless Internet gateway, in accordance with the principles of the 
present invention. 
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Table 1 shows an exemplary sample gateway configuration 
file for a wireless Internet gateway, in accordance with the principles of 
the present invention. 

Fig. 5 shows the provisioning capabilities of a wireless 
Internet gateway via a web page or from a remote wireless device, in 
accordance with the principles of the present invention. 

Fig. 6 shows exemplary wireless Internet gateway support of 
a simple mail transfer protocol (SMTP) mall server , in accordance with 
the principles of the present invention. 

Fig. 7A shows an exemplary mail send/receipt process flow 
in the direction from a wireless Internet gateway towards a wireless 
handset, in accordance with the principles of the present invention. 

Fig. 7B shows an exemplary mail send/receipt process flow 
in the direction from a wireless handset towards a wireless Internet 
gateway, in accordance with the principles of the present invention. 

Fig. 8 shows a redundant configuration for wireless Internet 
gateways, in accordance with the principles of the present invention. 

Figs. 9A to 9C and 10A to 10C show an exemplary software 
module hierarchy and relationships for a wireless Internet gateway 100 
implementing two-way messaging, in accordance with the principles of the 
present invention. 

Fig. 9B illustrates how messages would flow in an SMTP 

environment. 

Fig. 9C illustrates how messages would flow in an RMI 

scenario. 

Fig. 11 shows a conventional gateway providing Internet 
access to a wireless network through a short message service center 
(SMSC). 



DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS 

The present invention provides a wireless Internet gateway 
which bridges the gap between the Internet and wireless devices, e.g., via 
a short nnessage service center (SMSC). The disclosed architecture is 
5 modular, and provides a generic destination interface to any of a plurality 
of destination devices of any of a variety of protocols. This reduces 
redevelopment efforts to those required only between the generic 
destination interface and the particular destination device, eliminating the 
need for redevelopment of the application programming interface (API) up 
1 0 to the generic destination interface. 

In a particular disclosed embodiment the wireless Internet 
p gateway provides a portal to SMPP protocol messages using RMl 

techniques. However, the present invention has applicability to portals or 
:j gateways providing a communication path between RMl objects and any 

1 5 other type of wireless network messaging protocol, 
fij The disclosed embodiment of a wireless Internet gateway in 

"L.^ accordance with the principles of the present invention receives SMPP 

St messages on a wireless network side, translates those SMPP messages 

to RMl message objects, and re-transmits those RMl message objects to 
,pt 20 an application server having access to the Internet (or Intranet) (e.g., to an 
E-mail server, a chat server, voice messaging system, paging system, 
etc.). The wireless Internet gateway utilizes common protocols (e.g., 
SMPP) to allow operation with existing standard conforming wireless 
networks. 

25 in particular, the disclosed wireless Internet gateway is 

provided between the Internet using, e.g., HTTP protocols and a Short 
Message Service Center (SMSC) which communicates with wireless 
handsets over a wireless network using, e.g., SMPP protocols. 
^ Importantly, the wireless Internet gateway uses Java 

30 Remote Method Invocation (RMl) techniques to communicate with 
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relevant application servers using other transmission protocols of the 
Internet (or Intranet) (e.g., HTTP, SMTP relating to e-mail messages, 
etc.). The RMI techniques insert RMI message objects in the wireless 
Internet gateway, which are communicated to a generic destination 
5 interface. From the generic destination interface the messages are 
packaged into relevant messages of the particular destination protocol 
(e.g., SMPP), and transmitted to the relevant network element (e.g., to an 
SMSC). 

A wireless Internet gateway in accordance with the 
10 principles of the present invention effectively provides a shield for a 
wireless provider's short message service center (SMSC) from direct 
interaction with Internet clients. This provides a more secure environment 
from the perspective of the wireless provider, and allows the wireless 
provider the freedom to implement Internet access for wireless 
1 5 subscribers using existing otherwise non-Internet ready SMSCs. 

The disclosed wireless Internet gateway is flexible in that it is 
easily developed to support any input protocol (using RMI techniques with 
a relevant application server providing the particular input protocol), and 
any output protocol developed to package messages from RMI message 
20 objects passed to a generic destination interface into the particular output 
protocol. 

The standard protocol commands utilized by the disclosed 
wireless Internet gateway can be extended or added to software already 
existing in an SMSC or other appropriate element of a wireless system 
25 through the addition of an appropriate Application Programming Interface 
(API). Moreover, the wireless Internet gateway can serve as a messaging 
middleware layer for other applications. 

The wireless Internet gateway preferably is implemented so 
as to be capable of operating on a number of different platforms. One 
30 way of accomplishing this is by using software written in the Java 
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programming language. In this way, any operating system or hardware 
platform that supports the Java run time environment can be used to 
support a wireless Internet gateway application. For instance, a wireless 
Internet gateway application written in Java may be implemented on most 
operating systems, including Linux, HP-UX, Netware, Solaris (Intel and 
Sparc), and NT. 

An important feature of the present invention is the use of 
Java Remote Method Invocation (RMI) technology to provide an interface 
to other application servers, which in turn communicate over the Internet. 
In this way, application servers on the Internet are responsible for 
communicating over the Internet using other protocols (e.g., HTTP, 
SNMP, SMTP, etc.), or directly with a user. These application servers on 
the Intemet each then communicate with a wireless Internet gateway 
utilizing RMI techniques implemented in an appropriate gateway 
Application Programming Interface (API). The disclosed gateway API Is a 
collection of Java classes and their methods which use Java Remote 
Method Invocation (RMI) technology to pass data between an application 
server in communication with the Internet and the wireless Internet 
gateway. 

Thus, in accordance with the principles of the present 
invention, as long as an application server in communication with the 
Internet communicates with the wireless Internet gateway using RMI 
techniques, the application server Is free to utilize any other protocol on its 
front end to communicate over the Internet. 

Fig. 1 shows exemplary connectivity for a wireless Internet 
gateway, in accordance with the principles of the present invention. 

In particular, as shown in Fig. 1, a wireless Internet gateway 
100 together with appropriate application servers 110a, 110b, 110c bridge 
the gap between an off-the-shelf (OTS) short message service center 
(SMSC) 120 and the Internet 190. 



The SMSC 120 communicates with network elements of a 
wireless network 130. The SMSC 120 communicates with the wireless 
Internet gateway 100 using standard SMPP protocol commands. 

The wireless Internet gateway 100 in turn communicates 
5 with the Internet via one or more appropriate application servers 110a, 
110b, 110c preferably using a Java Remote Method Invocation (RMI) 
technique. 

The application servers 110a, 110b, 110c may utilize any 
appropriate front end to communicate with other servers via the internet 

10 190. For instance, one application server 110a may be configured to 
communicate over the Internet using HTTP protocols. HTTP protocols 
may be appropriate, e.g., when a wireless device in the wireless network 
130 desires to participate in a chat group hosted by a chat server 140 in 
communication with the Internet 190. In such a case, the wireless Internet 

15 gateway 100 will pass SMPP protocol messages with the SMSC 120, with 
utilize RMI techniques with the appropriate application server 110a, and 
the application sen/er 110a will translate the chat group postings into 
HTTP protocol messages for transmission via the Internet 190 to the chat 
server 140. 

20 Similarly, another application server may be configured with 

an appropriate application program to provide an SMTP front end 
presence on the Internet 190 to the wireless Internet gateway 100. In this 
way, wireless devices in the wireless network 130 may send and receive 
E-mail using SMPP protocol messages from the wireless network 130 to 

25 the SMSC 120 and to the wireless Internet gateway 100, which are 
passed to the appropriate application server 110b using RMI techniques, 
and translated by the application server 110b to the requisite SMTP 
protocol messages for transmission over the Internet 190. 

Other application servers 110c may provide other types of 

30 front ends in communication with the Internet 190, e.g., SNMP. 
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The Internet front end protocol interfaces shown in Fig. 1 as 
being provided by application servers 110a-110c may alternatively be 
integrated into the wireless Internet gateway 100. For instance, the 
wireless Internet gateway 100 may include appropriate application 
5 programs and interfaces to provide an SMTP interface directly to the 
Internet 190, avoiding the need for a separate application server 110 for 
that purpose. 

Similarly, the wireless internet gateway 100 may include 
integrated front ends for HTTP and/or SNMP protocol communication 

10 links with the Internet 190. Moreover, the wireless Internet gateway 100 
may interface directly with a local chat server 177. 

The wireless internet gateway 100 may have multiple 
provisions in its API for relaying data to and from the wireless devices in 
the wireless network 130 to the application servers 100. For instance, the 

15 wireless Internet gateway 100 may implement a queuing technique that 
attempts guaranteed delivery to a relevant wireless device through 
multiple transmissions if necessary. An example of a suitable application 
for the queuing technique is E-mail. 

Fig. 2 shows an exemplary application programming 

20 interface (API) of a wireless Internet gateway including a short message 
queuing mechanism and abstracted generic destination interface, in 
accordance with the principles of the present invention. 

In particular, as shown in Fig. 2, the wireless Internet 
gateway 100 provides an RMI handler 230 for handling receipt of RMI 

25 objects from RMI clients 232 (i.e., application servers 110). The RMI 
objects are inserted into a queue handler 200 by the relevant application 
sen/ers 232. Using RMI techniques, the particular front end protocol is 
'abstracted' away from the wireless Internet gateway 100 API. 
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In addition to RMI objects, e-mail messages are processed 
by an SMTP handler 240 as they are received and sent to Email 
application servers 242 

The queuing technique shown in Fig. 2 captures incoming 
5 messages into a message queue 205. The messages come from either 
RMI objects from the front end application servers 110, or as E-mail into a 
built-in mail server front end function 240 of the wireless Internet gateway 
100. Thus, E-mail messages from appropriate E-mail clients 242 on the 
Internet 190 are received and processed by an appropriate SMTP handler 
10 240, and passed on to a queue handler 200. 

In the embodiment shown in Fig. 2, the wireless Internet 
gateway 100 also includes a direct SMTP connection from a local 
application server 110d provided by an SMPP link proxy module 297. 
The SMPP link proxy module 297 allows direct insertion and removal of 
1 5 SMPP formatted messages into a SMPP delivery module 260. 

The integrated SMPP link proxy module 297 may 
communicate with the external application server llOd using any 
particular protocol. For instance, the SMPP link proxy module 297 may 
communicate with the external application server 110d using RMI 
20 techniques. Alternatively, the SMPP link proxy module 297 may 
communicate with the application server using, e.g., SMPP objects, etc. 
The application server may be, e.g., another wireless Internet gateway 
100. 

The SMPP link proxy module 297 is particularly useful for 
25 listening' to a particular port. A selected port can be monitored, and 
any/all messages sent to that port can be captured by the SMPP link 
proxy module 297, and passed to the local application server lOOd for, 
e.g., printing, display, transmission via the Internet, etc. 

The SMPP link proxy module 297 is optional. As shown, the 
30 SMPP link proxy module 297 provides a mechanism for messages from 
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the wireless network 130 to be passed to a particular application server 
110d, while the queue handler 200 is nnost efficient in passing messages 
from application servers 232 or e-mail application servers to a wireless 
device. However, the queue handler 200 can be implemented to handle 
5 messages in both directions to and from mobile devices. 

RMI objects inserted into the queue handler 200 by the RMI 
handler 230 allows for a generic approach to the Internet side of the 
wireless Internet gateway 100 separate from the particular protocol used 
(e.g., HTTP), whereas the use of a direct link such as the SMPP link proxy 

10 module 297 requires particular development and dedication to a particular 
protocol, e.g., to SMPP as shown in Fig. 2. While RMI techniques can be 
utilized for multiple application servers 110 utilizing any of a number of 
different types of protocols on its front end, the direct technique dictates a 
protocol-specific implementation. 

15 The queue handler 200 has access to a message cache 

directory 220, and to a messages database 210. When a message 
arrives its contents are stored in the message cache directory 220, and 
details about the message are stored in the messages database 210. 

Received messages are stored in the a message queue 

20 205. The message queue 205 orders the messages in an appropriate 
fashion, e.g., by their time of arrival. 

A queue monitor 250 in communication with the queue 
handler 200 and the message queue 205 is responsible for removing a 
message from the message queue 205 and sending the same on to the 

25 SMSC 120 via an appropriate SMPP delivery application module 260. 

If the SMSC 120 acknowledges receipt of the message, the 
message is then removed from the message cache directory 220 and 
marked as sent in the messages database 210. If, on the other hand, the 
SMSC 120 fails to acknowledge the message, the message is copied 

30 from the message cache directory 220 and placed back onto the message 
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queue 205 for a subsequent retransmission at the appropriate time. In 
this fashion, messages are retransmitted until they are received. 

A second exemplary provision of an API in a wireless 
Internet gateway 100 is the establishment and integration of a direct 
5 connection from a wireless Internet gateway to applications such as chat 
sessions. In particular, the wireless Internet gateway 100 may 
communicate directly with a chat server using, e.g., RMI techniques. 

The wireless Internet gateway 100 is capable of supporting 
features to give messages certain characteristics and/or to include 
10 particular information with a message. For instance, message priority, 
callback numbers and/or validity times may be included with messages 
handled by the wireless Internet gateway 100. 

In particular, messages can be given a priority. When a 
message has a particular priority, the priority is signaled to the SMSC 10, 
15 which in turn will expedite its delivery. 

Callback numbers may be inserted with a message by the 
wireless Internet gateway 100. Callback numbers provide a service which 
generally makes it easier for a recipient to respond to a particular received 
message. 

20 The wireless Internet gateway 100 may also mark messages 

with validity times. A validity time in a message allows a recipient to 

respond accordingly. 

When a response is received from the wireless device, the 

wireless Internet gateway 100 passes the message directly to the 
25 application server 100. This session occurs through RMI to provide for 

the addition of new direct communication servers such as chat servers 

and web page interfaces. 

When a short message of any type arrives at the wireless 

Internet gateway 100, the short message is examined for its type and 
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destination. The type and destination of the short message dictate how it 
is handled. 

For instance, if the received short message is an 
acknowledgement of a short message sent from the wireless Internet 
gateway 100, then a receipt acknowledgement of the short message is 
sent to the source of the short message. As another example, if the 
received short message is an E-mail destined for transmission over the 
Internet 190, then the E-mail message is passed to the relevant mobile E- 
mail application server (e.g., to the integrated SMPT mail server 300 or to 
an external SMTP application server 110c), which in turn sends the E-mail 
message to a mail relayerfor ultimate transmission over the Internet 190. 

In a like fashion, each short message received by the 
wireless Internet gateway 100 from a mobile device is sent to an 
appropriate (internally integrated or external) application server 110 for 
processing, e.g., to an HTTP server 110a for transmission over the 
Internet 190, to an SMTP E-mail server 300 for transmission over the 
Internet 190, etc. 

The queue monitor 250 may communicate directly to the 
SMPP delivery module 260 utilizing appropriate SMPP protocol 
messages. However, to further abstract the particular protocol 
requirements away from the wireless Internet gateway 100, a generic 
destination interface 271 may be inserted between the queue monitor 250 
(or other message source) and the destination handler. 

The generic destination interface 271 provides an interface 
between the particular protocol on the destination side of the wireless 
Internet gateway 100 (e.g., SMPP as shown using the SMPP delivery 
module 260), and the messages in the message queue 205. In this way, 
adaptation to other protocols need change only the support of the generic 
destination interface 271 with respect to the destination handler (260- 
263). 
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For instance, the SMPP delivery nnodule 260 nnay be 
replaced in the wireless Internet gateway 100 with, e.g., another wireless 
Internet gateway 261, an Internet gateway 262, or a paging terminal 263. 
While the SMPP delivery module 260, the wireless Internet gateway 261, 
5 the Internet gateway 262, and the paging terminal 263 are all shown 
together in Fig. 2, this is for convenience of explanation only. The 
disclosed embodiment relates to the implementation of only one of the 
destination handlers 260-263 in any one wireless Internet gateway 100, 

Fig. 3 shows the monitoring and control of the status of a 
10 wireless Internet gateway 100 in accordance with the principles of the 
present invention using a Simple Network Management Protocol (SNMP) 
manager 600. 

In particular, as shown in Fig. 3, SNMP acces to the wireless 
Internet gateway 100 may occur through Management Information Base 

15 (MIB) objects. The SNMP access can be considered to occur in three 
levels of abstraction: the top level 3 is the SNMP management console 
600, the middle layer 2 of abstraction includes the SNMP agent 610, and 
the bottom layer 1 of abstractoin includes the wireless Internet gateway 
100 and inserted RMl objects. 

20 When allowing direct communications between wireless 

devices and application servers, the relevant application server 110 binds 
to the wireless Internet gateway 100 and receives messages to and from 
the wireless device(s). These messages aren't queued but may be 
directly relayed from the wireless Internet gateway 100 to the SMSC 120 

25 and the wireless device when they are received. 

The status of the wireless Internet gateway 100 can be 
controlled and monitored by the Simple Network Management Protocol 
(SNMP) manager 600. For instance, the SNMP management console 
600 may initiate a status inquiry. The SNMP agent 610 inserts a query 
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status RMl object into the wireless Internet gateway 100, and the relevant 
status in the wireless Internet gateway 100 is obtained. 

The wireless Internet gateway 100 may communicate with 
the SNMP agent 610 of an appropriate application server 110b via an RMl 

5 interface. The SNMP agent 610 of the application server 110b in turn 
communicates to the SNMP Management Console 600. Using this 
facility, the wireless Internet gateway 100 may essentially become an 
SNMP device, and thus can be remotely monitored and managed, e.g., 
from the SNMP management console 600 or remote scripts and 

10 programs. 

Using SNMP management, the number of active SMPP links 
can be seen, the last error examined and other configuration changes 
made. In this way, the wireless Internet gateway 100 can be remotely 
reset if necessary or desired. 

15 SNMP access to the wireless Internet gateway 100 may 

occur using Management Information Base (MIB) objects. Each MIB 
object defines an item to monitor or control. The MlB's may in turn be 
translated into Java code using a conventional SNMP development 
package. The generated Java code gathers an internal value of the 

20 wireless Internet gateway 100, and makes it visible to the SNMP agent 
610. The code generated from an MIB object can also perform actions 
within the wireless Internet gateway 100 and in so doing, affect the state 
of the wireless Internet gateway 100 as desired. 

The SNMP agent 610 communicates using RMl protocol. 

25 Services requiring SNMP access preferably use methods defined by the 
SNMP agent 610, which in turn communicates with the SNMP 
management console 600 using SNMP protocol. 

SNMP traps, which reflect error or alert conditions in the 
wireless Internet gateway 100, go through the SNMP agent 610 for 
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display on the SNMP management console 600. Remote processes and 
scripts may also monitor these traps. 

Scripts and separate processes can talk SNMP remotely 
with the wireless Internet gateway 100. The code generated from the 
MIB's provides the interface to do this. This allows other monitoring 
processes to watch the wireless Internet gateway 100 and, for example, 
send notifications to an administrator if any problems occur. They send 
commands and configuration information as necessary also. 

Fig. 4 shows exemplary log and configuration files utilized by 
a wireless Internet gateway, in accordance with the principles of the 
present invention. 

In particular, as shown in Fig. 4, the wireless Internet 
gateway 100 may maintain message logs of its activity for local or remote 
monitoring. For instance, plain-text files may be made available to be 
accessed and viewed. As an example of a plain-text file, a message log 
may be accessed with a text viewer 800, e.g., a web page server using a 
LogView Java servlet running on the host machine implementing the API 
of the wireless Internet gateway 100. 

There are several files to which the text viewer 800 may 
provide access (e.g., read-only access). As shown in Fig. 4, they may 
comprise a systems log 810, an accounting log 830, a STDOUT log 850, 
and a STDERR log 820. 

The text viewer 800 can also show a configuration file 840 
for the wireless Internet gateway 100. The systems log file 810 may 
contain messages describing the operation of the wireless Internet 
gateway 100. 

Messages typically have a severity level associated with 
them, e.g., a severity level 1 indicating a serious error and severity levels 
2 through 9 being of decreasing severity. The text viewer 800 preferably 
filters and/or presents the messages based on their severity level. 
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The accounting log file 830 may contain a list of the 
messages sent through the wireless internet gateway 100. 

The STDERR log 820 and STDOUT log files 850 may 
contain messages from the API software of the wireless Internet gateway 
5 100, and may be used by the administrator of the wireless Internet 
gateway 100 to determine if any program errors have occurred. 

The wireless Internet gateway 100 can be statically 
configured at initialization time via the gateway configuration file 840. 

Table 1 shows an exemplary sample gateway configuration 
10 file 840 for a wireless Internet gateway 100, in accordance with the 
principles of the present invention. 

The gateway configuration file 840 may set such parameters 
as, e.g., the maximum message length, message transmission timeout, 
host names, and/or wireless device access number ranges. The gateway 
15 configuration file 840 may be a plain-text file which is created/modified 
with a standard text editor. The gateway configuration file 840 may 
contain configuration parameters in a tagged data format. Tagged data 
format is a descriptive term describing the configuration item and the 
item's value. 

20 One parameter that may be configured in the gateway 

configuration file 840 is a spam filter. Spam is unsolicited and unwelcome 
E-mail. By reading the spam configuration values as defined by 
appropriate spam parameters, the wireless Internet gateway 100 can 
prevent too many messages from the same sender going to a particular 

25 recipient. Also, the wireless Internet gateway 100 can prevent one sender 
from sending an excessive number of messages via the wireless Internet 
gateway 100. 

The wireless Internet gateway 100 may keep track of the 
number of messages a sender has sent and/or how many messages a 
30 particular recipient has received. 
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If the configuration values are exceeded, a message may be 
sent to the systems log 810. This provides, among other things, the ability 
for a wireless carrier to base a subscriber rate based on their own 
specifically monitored use of the internet (e.g., on a number of messages 
5 sent and/or received via a wireless Internet gateway 100). 

Support for internationalization may be included in the 
wireless Internet gateway 100. For instance, responses to users can be 
configured to reflect the language in the local region where the wireless 
Internet gateway 100 has been deployed. Internationalization may be 

10 implemented using Java property files and its internationalization APIs, 

As an example, to provide internationalization, the gateway 
configuration file 840 might contain the following two lines: 
LocaleLanguage es # ISO 639 language code 

LocaleCountry AR # ISO 31 77 country code 

15 This demonstrates how an administrator may specify which 

language and/or in which country the wireless Internet gateway 100 will 
operate. If the locale parameters are not present in the gateway 
configuration file 840, the language and country may default, e.g., to 
English (en) and the United States (US), respectively. 

20 The property files may include a corresponding es_AR string 

in the file name. For example, the SMPP.properties file (which implies 
en_US) may contain a number of possible error messages, e.g.: 



# ERROR / STATUS CODE DESCRIPTIONS 
25 ErrorCodeG=Message accepted 
ErrorCode1=Message too long 
ErrorCode2=lnternal Error: SMPP Command too long 
ErrorCode3=lnternal Error: Invalid SMPP Command ID 
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The SMPP_es_AR.properties file may include the following 
corresponding lines: 

# ERROR / STATUS CODE DESCRIPTIONS 
5 ErrorGodeO=Mensaje aceptado 

ErrorCode1=Su mensaje es demasiado largo 
ErrorCode2=Longitud de comando no valida 
ErrorCode3=ldentificaci6n de comando no valida 

10 User parameters may be restricted. For instance, to control 

which parameters a customer can configure, the wireless Internet 
gateway 100 may work with an encrypted license. The license may 
encapsulate a variety of parameters associated with a customer's license 
agreement. 

15 In particular, a third-party license generator may create a 

customer license in the form of an encrypted file containing all pertinent 
license information. This may be accomplished by running the license 
generator and providing it with the allowed configuration. An encrypted 
license file, e.g., smscgw.lic, may be deployed with the wireless Internet 

20 gateway 100. Thus, when the wireless Internet gateway 100 is started, it 
reads the license file and as it performs its functions, it may query the 
license properties and behave accordingly. 

Fig. 5 shows the provisioning capabilities of a wireless 
Internet gateway 100 via a web page or from a remote wireless device 

25 using an external SMPP(P) application server 1000, in accordance with 
the principles of the present invention. 

In particular, as shown in Fig. 5, SMPP Provisioning 
Protocol, also known as the SMPP(P) protocol, allows for the creation, 
modification and deletion of subscribers, paging subscribers and 

30 distribution lists within the SMSC 120. The wireless Internet gateway 100 
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may have provisioning capabilities provided via a web page on an 
appropriate PC or other computer device operating a web browser 1030. 
The web browser 1030 utilizes HTTP protocol messages to an 
appropriate HTTP server 110a, which in turn communicates with the 
5 SMPP(P) application server 1000, e.g., via the Internet 190 or an Intranet. 

Alternatively, provisioning for the wireless Internet gateway 
100 may be provided from a remote wireless device such as a Wireless 
Access Protocol (WAP) phone 1020. 

SMPP may be implemented as another application server 
10 110 using the RMI protocol as shown in Fig. 5 (or internally as shown in 
Fig. 2). In any case, the wireless Internet gateway 100 handles 
transmission and receipt of SMPP(P) messages with the SMSC 120. 

The wireless internet gateway 100 may include one or more 
integrated communication interfaces, e.g., simple mail transfer protocol 
15 (SMTP). 

Fig. 6 shows exemplary wireless Internet gateway support of 
a simple mail transfer protocol (SMTP) mail server, in accordance with the 
principles of the present invention. 

In particular, as shown in Fig. 6, a wireless Internet gateway 
20 100 including SMTP support includes an integrated SMTP mail server 300 
connected to the Internet 190. E-mail is passed between the integrated 
SMTP mail server 300 and the SMPP application programming interface 
260 of the wireless Internet gateway 100. 

The SMTP mail server 300 shown in Fig. 7 may insert 
25 messages into the message queue 205 shown in Fig. 2 directly, without 
the need to utilize RMI techniques. However, the wireless Internet 
gateway 100 may alternatively or additionally communicate using RMI 
techniques with a particular application server 100c which provides e-mail 
services. 
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The integration of the SMTP mail server 300 into a wireless 
Internet gateway 100 allows mail from standard E-mail clients 242 to be 
sent to the wireless Internet gateway 100 and ultimately on to wireless 
devices serviced by the SMSC 120 in communication with the wireless 
5 Internet gateway 100. The SMTP mail server 300 translates messages 
between SMTP protocol messages between the wireless Internet gateway 
100 and the Internet 190, and SMPP protocol messages between the 
wireless Internet gateway 100 and the SMSC 120. 

The SMTP mail server 300 may be part of the software 
10 constituting the application programming interface (API) of the wireless 
Internet gateway 100, and preferably otherwise operates as a standard 
mail server. 

In operation, the disclosed SMTP mail server 300 of the 
wireless Internet gateway 100 monitors a mail port defined by a 

15 configuration file for the wireless Internet gateway 100, and answers mail 
requests sent from E-mail clients 242. When an E-mail client 242 sends 
an E-mail message to a wireless device serviced by the SMSC 120, the 
wireless Internet gateway 100 receives and queues the E-mail messagefl. 
Then, the wireless Internet gateway 100 sends the E-mail message to the 

20 relevant SMSC 120 using SMPP protocol for transmission to the relevant 
wireless handset in the wireless network 130. 

The API of the wireless Internet gateway 100 may also 
ensure that an E-mail message is truncated if necessary, e.g., if the E- 
mail message is longer than the currently configured maximum message 

25 length. In addition, or alternatively, the API of the wireless Internet 
gateway 100 may be configured to break long E-mail messages up into 
several separate transmissions for transmission to the SMSC 120 and on 
to the relevant wireless handset in the wireless network 130. 

A user of a mobile device in a wireless network 130 

30 including a wireless Internet gateway 100 in accordance with the 
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principles of the present invention may initiate an E-mail message from 
their mobile device, and may receive a receipt therefore indicating that the 
destination has received and/or reviewed the E-mail message. In such a 
case, the wireless Internet gateway 100 will send the mobile originated E- 

5 mail message to an appropriate E-mail server 110c using RMI (if external 
to the wireless Internet gateway 100), and that E-mail server 110c will 
accomplish delivery of the E-mail message. 

In the disclosed embodiment, communications between 
wireless devices and the SMSC 120 of a wireless network 130 and the 

10 wireless Internet gateway 100 utilize messages conforming to standard 
SMPP v3.3 protocols for mobile terminated (MT) communications, with the 
following exceptions in the case of mobile originated (MO) 
communications: 

1 . The registered_delivery flag is utilized. 
15 2. A "$R" trigger exists in every message body 

indicating a source-unique tracking number. 

3. User responses are contained within the stat 
component of the standard delivery receipt. 

4. Message types are identified by the esm_class 

20 field. 

Alpha-numeric E-mail may be embedded in the source_addr 
field for a short message. In particular, E-mail addresses can be 
embedded in source_addr field for submit_sm messages, and in the 
destination_addr for deliver_sm messages. Such embedding provides an 

25 indication as to where the particular E-mail comes from, and where it 
should go. The conventional 20 character (or other length) limitation may 
be extended as necessary or desired for these particular fields. 

Figs. 8A and 8B show exemplary scenarios describing 
interaction between a mobile device, its SMSC 120, and a wireless 

30 Internet gateway 100 as an SMPP client, in accordance with the principles 
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of the present invention. In these exemplary scenarios, an E-mail 
message is communicated. 

Certain aspects of communications between mobile devices 
and the wireless Internet gateway are shown and described in co-owned 

5 U.S. Appl. No. 60/ , , filed by Richard A. Smith and 

Johanna Wilson, entitled "Short Messaging Service Center SMPP to 
HTTP Intemet Communications", the entirety of which is expressly 
incorporated herein by reference. 

Fig. 7A shows an exemplary message flow when a wireless 
10 Internet gateway 100 originates a short message requiring SME delivery 
acknowledgement and a response from the recipient, in accordance with 
the principles of the present invention. 

In particular, as shown in Fig. 7A, a wireless Internet 
gateway 100 sends a message to a mobile wireless handset device, and 
15 requests two types of delivery feedback: (1) acknowledgement of when 
the user reads the message; and (2) a response code from the user. 

The message is derived from an E-mail message received 
from the Internet to an address, e.g., "MIN@[gateway]". The wireless 
Internet gateway 100 supplies the sender's E-mail address so that it may 
20 be processed by the mobile wireless handset device. 

Note that in the preferred embodiment, the wireless Internet 
gateway 100 will not request delivery feedback of any kind when 
submitting short messages for incoming E-mail. 

In step 1 of Fig. 7A, the wireless Internet gateway generates 
25 a SUBMIT_SM message with key elements populated in the following 
way: 

- service_type: page 

- source_addr: [sender's E-mail address] 

- destination_addr: handset's MIN 

30 - registered_delivery_flag: 12 (bits 2&3 enabled) 
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- short_nnessage: $R[1 3-bit gateway id]$M[E-mail body] 

If the registered_delivery_flag is 0 or 1 , then the $R value is 

not required. 

In step 2 of Fig. 7A, the SMSC sends a standard 
submit_sm_response message. The response is matched to the 
submit^sm by sequence number. The body contains the SMSC- 
generated tracking number. 

In step 3 of Fig. 7A, the SMSC delivers the message to the 
mobile device in compliance with 637A. 

In step 4 of Fig. 7A, the user of the mobile device reads the 
message. A Delivery Ack is sent by the mobile device through the 
network to the SMSC. 

In step 5 of Fig. 7A, the SMSC generates a Deliver_SM 
message to the wireless Internet gateway using a Delivery Receipt 
template. The "stat" portion of the delivery receipt may use identical 
values as the normal SMSC Delivery Receipt. In the given example, the 
value for the esm_class is 8 (bit 3 enabled). 

The "text" portion of the delivery receipt will also include the 
$R trigger prior to any text, thus indicating the MO tracking number. This 
tracking number will be the same that was assigned by the original 
submit_sm in step 1 . A $M trigger following the $R value contains the first 
20 characters of the original short message. 

As an example, the "text" portion may contain 
"$R9998$MThis was a MO test". 

In step 6 of Fig. 7A, the user of the mobile device responds 
to the received short message with a keypress or other action which 
results in the generation of, e.g., a value of "3". 

In step 7 of Fig. 7A, the SMSC generates a Deliver_SM 
message to the wireless Internet gateway again using the Delivery 
Receipt template. In the given example, the "stat" portion of the message 
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contains the response code, e.g., "3". The esm^class value is "16" (bit 4 
enabled). 

As with step 5, the "text" portion of the delivery receipt is in 
the format $R[ref#]$l\/l [message text] 
5 The delivery feedback may be dependent on the 

registered_delivery_flag value. For example, a value of 8 (bit 3 enabled) 
may cause only the User Response code to have been returned. 

Fig. 7B shows a mobile device originating a message 
requiring SME delivery acknowledgement and a user response as it 
10 interacts with a wireless Internet gateway, in accordance with the 
principles of the present invention. 

In particular, as shown in Fig. 7B, a mobile device originates 
a message to the wireless Internet gateway, requesting both delivery 
receipt and a response code from the recipient The short message could 
15 be submitted to an E-mail address and the mobile device can request a 
delivery receipt to ensure that the short message was delivered 
successfully. 

If desired, User Response codes need not be supported for 
mobile originated E-mails. 
20 In step 1 of Fig. 7B, the mobile device generates a mobile 

originated short message addressed to a particular E-mail address. 

In step 2 of Fig. 78, the SMSC parses the destination 
address, determines that it is formatted like an E-mail address, and 
forwards it to the wireless Internet gateway over the SMPP (rx) 
25 connection. 

A Deliver_SM message is generated with the following key 

field values: 

- service_type: page 

- source_addr: [handset's MIN] 

30 - destination_addr: [destination E-mail address] 
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- registered_delivei7_flag: 12 (bits 2&3 enabled) 

- short__message: $R[new ref id]$M[message] 

The [new ref id] may be generated by the mobile device and 
forwarded by the SMSC through the $R trigger. 
5 In step 3 of Fig. 7B the wireless Internet gateway generates 

a deliver_sm_resp code. This contains the internal tracking number of the 
wireless Internet gateway within the message body. The sequence 
number matches that of the Deliver_SM. 

In step 4 of Fig. 7B, the wireless Internet gateway has Yead' 
10 the short message, and generates a delivery receipt to the SMSC. For 
example, it would generate a delivery receipt showing the result of an 
attempt to forward the E-mail message. 

The delivery receipt may be formatted as shown and 
described with respect to step 5 in Fig. 7A. In particular, the "stat" field 
15 contains the status code and the "text" field contains the $R[ref 
id]$M[message] content. The Reference ID value is the same as received 
from the deliver_sm in step 2 of Fig. 7B. The esm_class is 8. 

In step 5 of Fig. 7B, the delivery message is forwarded to 
the mobile device. 

20 In step 6 of Fig. 7B, if the wireless Internet gateway were to 

provide a response code, it would generate a delivery receipt with the 
response code within the "stat" element and the esm_class = 16. This 
would be passed through a submit_sm message to the SMSC. Of course, 
delivery receipt need not be implemented in any particular application. 

25 In step 7 of Fig. 7B, the SMSC will forward the response 

code to the mobile device. 

Fig. 8 shows a redundant configuration for wireless Internet 
gateways 100, in accordance with the principles of the present invention. 

In particular, as shown in Fig. 8, a wireless Internet gateway 

30 100 in accordance with the principles of the present invention can be 
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configured to run redundantly on separate hardware platforms. In this 
environment, separate wireless Internet gateway servers 10, 20 can be 
configured to share the workload of client processing and/or serve as hot- 
standby servers. 

5 A first wireless Internet gateway 10 provides communication 

between an SIVISC 120 and the Intemet 190. Similarly, a second wireless 
Internet gateway 20 provides communication between the SMSC 120 and 
the Internet 190. A network redirector device 1120 evenly distributes 
incoming traffic between the first wireless Internet gateway 10 and the 

1 0 second wireless Internet gateway 20. 

Each of the first and second wireless Internet gateways 10, 
20 are given access to separate databases 1110, 1112 in which they 
each maintain information about their respective messages. The first 
wireless Intemet gateway 10 can be designated as the primary device, 

15 with the corresponding database 1110 designated as the primary 
database. The second wireless Internet gateway 20 and corresponding 
database 1112 can be designated as secondary devices. 

As messages are processed on one wireless Internet 
gateway 10, 20, appropriate database software may synchronize 

20 information with the other database(s). 

Upon failure of a primary wireless Internet gateway 10, the 
network redirector 1120 transparently routes the failed wireless Internet 
gateway's traffic to the remaining wireless Internet gateway(s) 20. In this 
way, any pending messages from the failed wireless Internet gateway 10 

25 will not be lost because they will have been sent not only to the database 
1110 corresponding to the failed wireless Internet gateway 10, but also to 
the other database(s) 1112 corresponding to the secondary, backup 
wireless Internet gateway(s) 20. 

Redundant architecture such as that shown in Fig. 8 

30 includes primary wireless Internet gateway databases 1110, and 
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secondary wireless Internet gateway databases 1112 maintaining 

information about short messages. 

The first and second wireless Internet gateways 10, 20 may 

ordinarily share the load imposed upon them. However, if one wireless 
5 Internet gateway 10, 20 should fail, its messages may be automatically 

redirected by the network redirector 1120 and then handled by one of the 

redundant wireless internet gateways 20. 

The wireless Internet gateway 100 provides an abstracted 

mechanism for sending mobile terminated (MT) messages, where the MT 
10 delivery protocol is encapsulated from other GW software components. 

Using the generic destination interface 271 , two-way messaging may be 

implemented to support any relevant protocol, e.g., SMPP, Reflex, SNPP, 

SMTP, and other protocols. 

Two-way messaging may be enabled and disabled in the 
15 same way that the RemoteSMPP and other pieces are controlled. The 

configuration file 840 may define whether or not two-way messaging is 

enabled, and/or an encrypted license file may also include permission to 

enable two-way messaging. 

Figs. 9A to 9C and 10A to IOC show an exemplary software 
20 module hierarchy and relationships for a wireless Internet gateway 100 

implementing two-way messaging, in accordance with the principles of the 

present invention. 

In particular, the exemplary two-way messaging software 

package hierarchy may be implemented, e.g., with a number of key 
25 components: 

TwoWayMessage 708, which is an independent 
Message class for 2-way communication. 

ImessageReceiver 706, which classifies objects able 
to receive TwoWayMessages. 
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ImessageSender 704, which classifies objects able to 
send TwoWayMessages. 

Registrar 702, which facilitates connecting receivers and 

senders. 

5 A Config class 712 may be configured to interact with the 

Registrar 702 at runtime in order to dynamically assign sender/receiver 
relationships. A sender can have any number of receivers. 

Sub-packages define particular aspects of the 2-way 
capabilities. For example, an *smtp' sub-package 720 defines a Sender 

10 and Receiver that know how to send and receive SMTP 2Way Messages. 
The TwoWayMessage class 708 is abstract; subclasses provide details 
specific to particular protocols being used. This allows the handlers to set 
and retrieve protocol-specific parameters, while still allowing the 
messages to be treated in a generic manner. 

15 A 'remote' package 722 provides a mechanism for remote 

RMI objects to register as 2-way message receivers and senders. This 
approach is akin to the RemoteSMPP module, where external apps can 
register as SMPP listeners as well as originate SMPP messages into the 
wireless Internet gateway. However, this approach is preferable because 

20 it is not tied to a particular protocol. 

Protocol handlers within the wireless Internet gateway 100, 
such as the SMTP handler 240 (Fig. 2) and the SMPP Delivery module 
260 will interact with the two-way software modules. Thus, if a generic 
two-way feature is enabled in the config file 840, then the SMTP and 

25 SMPP listeners will also forward (select) traffic through the two-way 
module to be delivered to potential listeners. 

The API software of the wireless Internet gateway 100 
preferably allows objects both within and external to the wireless Internet 
gateway 100 to receive and send messages in a protocol independent 

30 manner. 
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Integrating listeners and senders can be simplified and 
configurable at runtime through the use of the configuration file 840. This 
is especially true of external applications that wish to register a listeners 
for particular message senders. 
5 The wireless Internet gateway 100 preferably gracefully 

handles 'disconnected' Remote applications. If an external application is 
stopped or re-started, the wireless Internet gateway 100 preferably logs 
an error and cleans up all internal references occupied by the remote 
application. 

10 Using two-way messaging, a Mobile Terminated Receiver 

object may be made available in the wireless Internet gateway 100 by 
which messages can be delivered into the message queue 205. 

Fig. 9B illustrates how messages would flow in an SMTP 

environment. 

15 In particular, as shown in Fig. 9B, a 

2WaySMTPListenerAgent 730 implements an IMessageSender interface 
704. It is therefore able to send messages to whatever 
ImessageReceivers 706 might want to register with it. The 
2WaySMTPListenerAgent 730 would be optionally created by a 

20 tcs.ain.smsgw.SMTPSession class. Whenever SMTP messages are sent 
to a particular address, they are sent to the 2WaySMTPListenerAgent 730 
rather than delivered into the message queue 205. 

The 2WaySMTPListenerAgent 730 then fonA/ards the 
message (step 2.1) to each IMessageReceiver object 706 that had 

25 registered with it through the addReceiver() function in step 1.1. When 
the 2WaySMTPListenerAgent 730 tells the receiver to process the 
message, it includes three parameters: itself (the Sender), a "Return Path" 
IMessageReceiver object 706 through which responses can be made, and 
finally the message itself. 
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In this example, the message is sent to 'App' 733, which 
implements both the sender and receiver interfaces. After App 733 
receives and processes the message, it will want to send a response 
back. Reponses must be returned to the Yeturn path' IMessageReceiver 
5 object 706 that was provided when the message was received. Since 
App 733 is also a sender, it can directly send the response message to 
the return path receiver. 

In this case, the SMTPDelivery Agent 735 is the receiver that 
had been specified. The message is received by the SMTPDeliverAgent 
10 735 (step 3), and then forwarded back to the user. 

Fig. 9C illustrates how messages would flow in an RMI 

scenario. 

In particular, RMI is a bit more complicated, but similar in 
nature. As shown in Fig. 9C, a Remote2Way object 740 brokers the 

15 Inside' and 'outside' worlds. It ensures that references are cleaned up if 
the remote client should disconnect or fail. It also helps ensure that the 
core classes do not worry about RMI details at all. For every remote 
object that binds through the Remote2Way 740, a local 'proxy' object is 
created which actually binds to the specified senders and relays 

20 messages back and forth through the Remote2Way 740. 

As indicated previously, the Registrar 702 is used to 
facilitate connecting receivers to senders. This can be done by explicitly 
passing in sender and receiver objects to the registrar 702. However, one 
can also assign unique identifies to senders and receivers, and then 

25 reference either by their ID rather then by the actual object. This latter 
approach is useful for objects that need to be connected at runtime, as 
defined by a configuration file 840. 

In the above scenario, the Config object 712 assigns an ID 
to a sender object. A remote app 741 then binds to the wireless Internet 

30 gateway's Remote2Way interface 740 and requests to be a listener for the 
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sender with the same given ID. Remote2Way 740 creates a 
ProxyReceiver 742 for the remote object, and then uses the Registrar 702 
to register the proxyReceiver 742 as a listener to the Sender with the 
specified ID. 

5 When the Sender sends a message, it will be delivered to 

the proxyReceiver 742, which forwards it to Remote2Way 740, which then 
goes to the remote object 741. The remote object 741 can then reply with 
a message, which will be sent via Remote2Way 740 to the ProxyReceiver 
742, which will ensure that it gets delivered to the ReturnPath Receiver 
1 0 that was originally specified when the Sender sent the message. 

Remote2Way 740 also provides methods for originating new 
messages directly to senders. So, the remote app 741 can do more than 
just reply. 

A wireless internet gateway 100 in accordance with the 
15 principles of the present invention is particularly useful for wireless carriers 
and/or Internet service providers (ISPs). For instance, a wireless Internet 
gateway 100 can also be used within the Enterprise and ISP markets to 
provide a single point of entry for short message system (SMS) delivery to 
multiple wireless carriers. This is detailed in a co-owned U.S. Appl. No. 

20 60/ , , filed by Richard Smith, and entitled "Web 

Gateway Multi-Carrier Support", which in its entirety is explicitly 
incorporated herein by reference. 

While the invention has been described with reference to the 
exemplary embodiments thereof, those skilled in the art will be able to 
25 make various modifications to the described embodiments of the invention 
without departing from the true spirit and scope of the invention. 
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CLAIMS 



What is claimed is: 

1. A wireless Internet gateway, comprising: 
5 a Java Remote Method Invocation (RMI) handler; 

a destination handler; and 

a message handler between said RMI handier and said 
destination handler; 

wherein RMI objects are inserted in said message handler 
10 by an application server in communication with said RMI handler. 



wherein: 



15 



wherein: 



2. The wireless Internet gateway according to claim 1, 



said destination handler utilizes SMPP protocols. 



3. The wireless Internet gateway according to claim 1, 



said destination handler utilizes HTTP protocols. 



20 4. The wireless Internet gateway according to claim 1, 

wherein: 

said destination handler utilizes TNPP protocols. 



5. The wireless internet gateway according to claim 1, 
25 further comprising: 

an SMPP link proxy module providing direct communication 
between an application server and said destination handler. 
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6. The wireless internet gateway according to claim 1, 
further comprising: 

a message queue; 

wherein messages contained in RMI objects in said 
5 message handler are queued for transmission to a destination in said 
message queue. 

7. The wireless Internet gateway according to claim 1, 
further comprising: 

10 a generic destination interface between said message 

queue and said destination handler. 

8. The wireless Internet gateway according to claim 1, 
further comprising: 

15 a chat server in communication with said RMI handler. 

9. The wireless Internet gateway according to claim 1, 
further comprising: 

an e-mail server in communication with said RMI handler. 

20 

10. The wireless Internet gateway according to claim 1, 
further comprising: 

an SMTP handler in communication with said handler. 
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1 1 . A wireless Internet gateway, comprising: 

a Java Remote Method Invocation (RMI) handler; 
an SMPP delivery handler; and 

a message handler between said RMI handler and said 
SMPP delivery handler; 

wherein RMI objects are inserted in said message handler 
by an application server in communication with said RMI handler, directed 
to said SMPP delivery handler for delivery to a wireless device using 
SMPP protocols. 

12. A method of providing communications between a 
wireless network and the Internet, comprising: 

accepting an RMI object from an application server in 

communication with the Internet; 

extracting a short message from said RMI object; and 
passing said short message to a destination handler for 

transmission to said wireless network. 

13. The method of providing communications between a 
wireless network and the Internet according to claim 12, further 
comprising: 

monitoring short messages relating to a particular 
destination subscriber for billing purposes based on a number of short 
messages communicated with said destination subscriber 
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14. The method of providing communications between a 
wireless network and the Internet according to claim 13, wherein said step 
of passing comprises: 

passing said short message to a generic protocol destination 

5 interface; and 

passing said short message from said generic protocol 
destination to said destination handler. 

15. The method of providing communications between a 
10 wireless network and the Internet according to claim 13, further 

comprising: 

adding a parameter to said short message in a wireless 
Internet gateway. 

15 16. The method of providing communications between a 

wireless network and the Internet according to claim 13, wherein said 
added parameter comprises: 

a message priority level. 

20 17. The method of providing communications between a 

wireless network and the Internet according to claim 13, wherein said 
added parameter comprises: 

a callback number. 

25 18. The method of providing communications between a 

wireless network and the Internet according to claim 13, wherein said 
added parameter comprises: 
a validity time. 
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19. The method of providing communications between a 
wireless network and the Internet according to claim 13, wherein said 
added parameter comprises: 

a delivery receipt request. 

5 

20. The method of providing communications between a 
wireless network and the Internet according to claim 13, further 
comprising: 

logging details about said short message in a messages 

10 database. 

21. The method of providing communications between a 
wireless network and the Internet according to claim 13, further 
comprising: 

1 5 storing contents of said short message in a message cache. 

22. Apparatus for providing communications between a 
wireless network and the Internet, comprising: 

means for accepting an RMI object from an application 
20 server in communication with the Internet; 

means for extracting a short message from said RMI object; 

and 

means for passing said short message to a destination 
handler for transmission to said wireless network. 
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23. The apparatus for providing communications between a 
wireless network and the Internet according to claim 22, wherein said 
means for passing comprises: 

means for passing said short message to a generic protocol 
5 destination interface; and 

means for passing said short message from said generic 
protocol destination to said destination handler. 

24. The apparatus for providing communications between a 
10 wireless network and the Internet according to claim 22, further 

comprising; 

means for logging details about said short message in a 
messages database. 

15 25. The apparatus for providing communications between a 

wireless network and the Internet according to claim 22, further 
comprising: 

means for storing contents of said short message in a 
message cache. 

20 

26. The apparatus for providing communications between a 
wireless network and the Internet according to claim 22, further 
comprising: 

means for receiving an e-mail message from an SMTP 

25 handler; and 

means for passing said e-mail message to said destination 
handler for transmission to said wireless network. 
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27. The apparatus for providing communications between a 
wireless network and the Internet according to claim 22, further 
comprising: 

means for adding a parameter to said short message in a 
5 wireless Internet gateway. 



28, The apparatus for providing communications between a 
wireless network and the Internet according to claim 22, wherein said 
means for adding a parameter adds at least one of: 
1 0 a message priority level; 

a callback number; 
a validity time; and 
a delivery receipt request. 



15 29. A method of providing an encrypted license to a system 

user, comprising: 

establishing at least one adjustable parameter having a 
maximum range for said system; 

encrypting a license file with an enablement of said 
20 adjustable parameter; and 

limiting a range of said adjustable parameter using said 
encrypted license file, within said maximum range based on a level of use 
granted to said system user. 

25 30. The method of providing an encrypted license to a 

system user according to claim 29, wherein: 

said system is a wireless Internet gateway. 
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31. Apparatus for providing an encrypted license to a 
system user, comprising; 

means for establishing at least one adjustable parameter 
having a maximum range for said system; 
5 means for encrypting a license file with an enablement of 

said adjustable parameter; and 

means for limiting a range of said adjustable parameter 
using said encrypted license file, within said maximum range based on a 
level of use granted to said system user. 

10 

32. The apparatus for providing an encrypted license to a 
system user according to claim 31 , wherein: 

said system is a wireless Internet gateway. 
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ABSTRACT 

A wireless Internet gateway which bridges the gap between 
the Internet and wireless devices, e.g., via a short message service center 
(SMSC). The disclosed wireless Internet gateway provides a portal to 

5 SMPP, HTTP, TNPP, or other protocol messages using Java Remote 
Method Invocation (RMI) techniques. Application servers (e.g., in 
communication with the Internet or an Intranet) insert RMI objects 
containing messages in a message queue handler of the wireless Internet 
gateway. The RMI objects are queued and passed either directly to a 

10 destination delivery handler (e.g., SMPP, SMTP, HTTP or TNPP protocol 
handler), or passed through a generic destination interface to provide an 
additional layer of abstraction to simplify development of the support of 
other destination protocols. An SMTP handler may be integrated into the 
wireless Internet gateway to provide direct communication of SMTP 

15 protocol messages (i.e., e-mail) to the message queue. An SMPP link 
proxy module may be implemented to provide direct access between a 
local application server and the destination delivery handler. The SMPP 
link proxy module is particularly useful in the direction from the wireless 
network to the application server. From the generic destination interface 

20 the messages are packaged into relevant messages of the particular 
destination protocol (e.g., SMPP), and transmitted to the relevant network 
element (e.g., to an SMSC). The disclosed wireless Internet gateway is 
flexible in that it is easily developed to support any input protocol (using 
RMI techniques with a relevant application server providing the particular 

25 input protocol), and any output protocol developed to package messages 
from RMI message objects passed to a generic destination interface into 
the particular output protocol. 
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GMat! Oi^nts 



/oo 



— ii;^ 




OMI HarxJIer 



1 



SMTP Haooier 



Queue Karxsec 




swsc 



1 1 

r ~/-] 

L > 

r '^^i 

^ ! 

1 -_J 



SNMP Management Console 



SNMP Agent 

("^ses SNMP stacx) 



SNMP G«VS«< 

_1 



RMi ConrwctKxi 
SNt^Traps 



C 



RMI Clients for SNMP 
insifufnentatton 



-RMI- 



RMf Objects 
(norvgateway speofk:) 




RMI Clients 
in Gateway 



RMl Objects 
to Gateway 



! 



Op«f»t<tq System 



Wtreless Internet Gateway 
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SNMP^ttway lnt«ffacM 



smscgw conf; Con f iqu ca t ion Pile for ICS SMS Wet) Gateway 
(c) 1998. 1S99. 2000 TCS, Inc, 



GW_ID 
GWName 



Identification 

A 

d<jmin$ demos ys . com 

0000000009 



System Output 



bdsedir 

accountip.giogfile 
s ys temioq file 
account mg Icq level 
sys temioqieve i 
debuqmode 



/ 

loqs/acc log 
logs/system log 
9 
9 

yes 
yes 



* Msg Identifier for GW 

« Email address for gw msgs 

# MIN to shutdown gateway 



i base location of files 

» account log file name 

It system log file name 

» Level of accounting log detail 

I* Level of system log detail 

# Sends SMPP info to StdOut 

* Show SMTP Interactions 



smtpSocy.etTimeour 
smtpSocketLmge!: 



10 
10 



smtpLiscenerSleepInterval 50 



# Time socket waits for input 

# before it times out 

« Time OS keeps soOcet alive 

# after application closes socket 
» Time (miliisecondsl to pause 

« between successive SMTP connections 

# 50 miilieseconds implies 200 

# connections per second 



H Database References 

MessageStoreType OB 



# file System (FS) or Database 

« (DB) storage or None or 08 Cacne(DBC) 



* Connection information for accessing the Message Store 



Me s sages to reObC lass 

MessageStoreDbUrl 

Me s sages tor eObAccount 

^^essageStoreDbPw 

-nsgLi f espanHours 
reque Interval Sees 



oracle- 3dbc -driver . OracleDriver 
]dbc: Oracle : thin : 8dbhost . demosys . com: 1521 :ORCL 
webdb 
private 
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« How long to retain message data 
t How often to requeue unack'd msgs 



q_cach<p4th 



/each*/ 
. /trvessaqes/ 



P«ndingC4CheThr<ahold SO 
PoilPendmgCache 10 



i directory for unack'd mag indicators 
« dic€ctocy for FS database files 



Features 



enable_smtp 
smtp_port 
enabIe_weD 
endbie_smpp 
enable calendar 



enable _moni tor 
meiT\ory Check Re St Time 
memorythceshhold 

msg^max len 
msg_I ink_rT\axien 

er\abie_antispam 

SparnMaxSendQty 

SpamMaxRecvOty 

SpamTimePeriod 

SpamlnValidSenders 

SpamValidSenders 

SpamVaiidReceivers 



yes 

25 
yes 



ves 

180000 
256 

90 
150 



yes 

100 
100 

I 



654.321,000 



admin^demosy* .com 



I Enable Email Support 

# Port for receiving email 

I Enable mi for Web (and other RMI clients) 

» Enable SMPP output to SMSCs (reqd) 

# Enable Web Calendar support 

# Enable free -nemory monitor 

» ms time for cnecking avbl memory 

# chreshoic tot generating alert 

% Ma/, length m a single message 

# Ma/ total length of msg through linking 

# Enable msg qty liiuitations 

» Max no. msgs that can be sent p«r period 
i Max no. msgs that can be recvd per period 

# Time period, m hours 

i Senders that are always refused 

# Sender exempt from anti-spam checks 



98^6543210, 123456"?890 # Receivers exempt from anti-spam checJcs 



forceSNReturnReceipt no 

AlwaysDoEmailReceipt no 

Always DoEmailReceipt_£xclude demos ys . com 

validateScneme 0 

suppottAitAddressmg yes 

mmLength 10 

PmLength 6 

PinPrefix P. 

supportSubmitTranslate no 



# Always request return receipt from SMSC 

I Always send a receipt to E-maii senders 

# Senders to exclude if above is enabled 

# 0*RANGE, 1-LOOSE, 2-EXPLICIT 

i PIK/Alias lookups allowed 
I Length of a valid MIN 

# Length of a s^alid PIN. 

t Prefix to Identify PINs 

# Do User vs Submit Address (DN/MIN) xiation 



heactbeatsecs 
heartbeat 



180 



Iseconds between heartbeats. 0 



sn count 



sn_typeO 



Message Destinations 

1 



# Number of SMSCs attached 



tcs , ain . siasgw . SmsGwSNSMPPLinh 



serializeSmppTraf fxc yes 



smpp_hostO 
saipp~TXportO 
smpp^RXportO 
smpp_b iad_p*3 3 wo rdO 

smpp^binid_sy s I DO 
s mpp_b ind_a y s Typ« 0 
smpp_vali5_ain_rangtO 
smpp^t ea^il* t«0 
smpp"callbac)c_trigg«rO 
stapp_mes5age_triggerO 
smpp_service_typeO 
5mpp_5 rc_addr_conO 
smpp_src_addr_npiO 
smpp_dst_addr_tonO 
smpp_dst_addr_npiO 



localhost # Host name of first SMSC 

7001 t SMPP Tx port for first SMSC 

1002 « SMPP Rx port for first SMSC 

secret # SMSC/SMPP Password 

EE I SMSC/SMPP System ID 

INET GW « SMPP Client identifier 
3102800000 5102802000 0000000009 OQOOOOOOOS 

i I SMSC Ten^3late for sending messages 

$A « Trigger for embedding callback number 

SM * Trigger for identifying message text 

p;^G£ * Service Type; Cownent out for Aidiscon 

0 # Type of Number; TCS-0 

0 # Numbering Plan Indentity; TCS»0 



Table 1 -Sample Gateway Configuration File 
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SMPP(P) Application 





Wtfetess Internet 


— ^ 


Gateway 








SMPP(P) Interfaces 




00 



XT 



1- ' »i_bnu.t_jir, ir»-2, SR."^' 



2 • JuD-n^t_siH_r«»p' 



6- '-xr r«tpofn<' fli 



Mail Send/Receipt Process from Gateway 
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/OO 



3 d*..t/«r_»r_r*»p' 



O 
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m 
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Mail Send/Receipt Process from Handsftt 



f 6. IS 



life 




Redundant Configuration 

0^ Wv\4A-a> lA/^cx.4UL:t Gq.i«-u;cu^ 



Registrar 



1/register recvr with 5^:ier 



Conf ig 



ri . 1/addReceiver (rcvr) 



IMessageSender 



2/handleMessage ( this, return path rcvr, msg) 



IMessageReceiver 



AX 



RMI Scenario 



O 

m 

m 
o 

H 

m 

Q 

m 

Q 

m 

u 
Q 



Registrar 



l/assignSenderId(iT^— 



Config 



IMessag^Sender 



IMe s s ageReceiver 



[2 .2/register (sender id, recvr) 



3.1/ sendToRemote ( this , msgT^ 
2.1/nevr-E»" 

4 - l/processResponseMsg (msgld, msg)' 



^^3/handleKessage (^his , return path rcpt, 



4 1 , 1/handleMessage 



V 



?3 1. 1/handleMessage (msg) 

*2/bind (senderld) 

M /sendResponse (msgid, rasg} 



ProxyReceiver 



Remotie2WayApp 



Fig- 9C 



Core 



#senderIds:Hashtable 
#receiverIds:Hashtable 



#addRecipient : void 
+setConstantSender : void 
+setConstantReceiver : void 
+register : void 
+register : void 
+register :void 
+register : void 
+getSender: IMessageSender 
+getReceiver: IMessageReceiv 



interface 
JMassageSender 



+setParanieter , void 
+addReceiver • void 
+reinoveReceiver void 



interface 



•'■setParaineter. void 
+handleMessage void 



J 



3ava. lo.Serializ 



-GetUniqueldiStri 
+TwoWayMessage 



body:String 
senderAddr:Strin 
destAdar:String 
uniqueldrString 
clientid: mt 
createDate : Date 



T" 
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Exceptio 
IdNotPef inedExeeption 



*-IdNotDefinedExcepti 



Exceptio 
IdNotUniqueExcept^-on 



+IdNotUniqueExceptio 



Exceptio 
Proce s sMes sageExcep t ion 



+ ProcessMessageException 



JihstractSender 



^receivers : Vector 



+addReceiver : void 
+reitioveReceiver : void 
#deliverroRecipients: V 



+handleMessage: void 
parameter:String 



1 r 


smtp 


1 


+SMTPTwoWayMessage 

+SMTPReceiver 

+SMTP2WayAgent 

-t-tcs,ain sinsgw, twoway Ahstrac 
+ tcs,ain.siusgw, twoway. IMessag 
+ tcs.ain.smsgh' twoway TwoWayM 


tests 


stl 

stMessage 





remote 



+ JiJeroo t eMessa geHece iv&r 

+ ProxyRece 1 ver 

+IRemote2Way 

+Reitiote2Way 

+ IRemo te2Wa yApp 



Remote 



3 ava . rmi . Remot 
interface 
IRemote2Way 



+bindToSen<ier:void 
+sendResponse : void 
+sendToConstantReceiver:voi 



R6mote2Way 



+bindToSender : void 
+sendResponse : void 
+sendToConstantReceiver: vo 
+sendToRemotG : void 



J ava . rmi , Remot 
interface 
IReiaoteMessageRecelver 



•i-handleMessage :void 



j ava , rmi . Remot 
interface 
IRGmo te2 WayJipp 



-hhandleMes sage : void 



IMessageReceive 
ProxyReceiver 

-msgIdToReturnPath:Hashtable 
+handleMessage : void 
+unregisterFromAllSenders : vo 
+registerWithSender: void 
+processResponseMessage : void 
parameter : String 



SMTP 



java. io. Seriali 
. tvoway .TwoVayMessage 



-GetUnicfueld: Stri ng 
+TwoWayMessage 



body : String 
senderAddr: String 
destAddr: String 
uniqueld : String 
clientid: int 
createDate : Date 



SMTPTwoWayMes sage 



+SMTPTwcWayMessage 



IMessageSender 
. smscrv. tvoway.AbstractSender 



^receivers: Vector 



+addReceivGr : void 
+reTnoveReceiver : void 
#deli verToRecipients : void 



X 



■5^ 



SMTP2 WayAgen t 



#returnPath: IMessageReceiv 



+SMTP2WayAgent 
-j-processSmtpData ; void 



parameter : String 



interface 
. . tvoway. IMessa.geRece±VGzr 



-hsetParameter :void 
■hhandleMessage : void 



J 



1 



SMTPReceiver 



#relayHost : 


String 


irelayPort : 


int 


+handleMes£ 


age: voi 


parameter : 


String 
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IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 
Declaration and Power of Attorney 

As below named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below next to iny name. 

I believe I am the original, first and joint inventor of the subject matter which is claimed and 
for which a patent is sought on the invention entitled WIRELESS INTERNET GATEWAY, 
the specification of which is attached hereto. 

I hereby state that I have reviewed and understand the contents of the above-identified 
specification, including the claims, as amended by an amendment, if any, specifically referred to 
in this oath or declaration. 

I acknowledge the duty to disclose all information known to me which is material to 
patentability as defined in Title 37, Code of Federal Regulations, 1.56. 

I hereby claim foreign priority benefits under Title 35, United States Code, 119 of any 
foreign application(s) for patent or inventor's certificate hsted below and have also identified 
below any foreign application for patent or inventor's certificate having a filing date before that 
of the application on which priority is claimed: 

None 

I hereby claim the benefit under Title 35, United States Code, 120 of any United States 
application(s) listed below and, insofar as the subject matter of each of the claims of this 
application is not disclosed in the prior United States application in the manner provided by the 
first paragraph of Title 35, United States Code, 112, I acknowledge the duty to disclose all 
information known to me to be material to patentability as defined in Title 37, Code of Federal 
Regulations, 1.56 which became available between the filing date of the prior application and the 
national or PCT international filing date of this application: 

U.S. Provisional Application Serial No. 60/199,367, filed April 25, 2000 

I hereby declare that all statements made herein of my own knowledge are true and that all 
statements made on information and belief are believed to be true; and finther that these 
statements were made with the knowledge that willfiil false statements and the like so made are 
punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the United States 
Code and that such willful false statements may jeopardize the validity of the application or any 
patent issued thereon. 



-2- 



20-465 



I hereby appoint the following attorneys with fiill power of substitution and revocation, to 
prosecute said apphcation, to make alterations and amendments therein, to receive the patent, and 
to transact all business in the Patent and Trademark Office connected therewith; 



Wilham H. BoUman 
Edward J. Stemberger 
Jeffrey S. Melcher 
W. Warren Taltavul 
Leon R. Turkevich 



(Reg. No. 36,457) 
(Reg. No, 36,017) 
(Reg. No. 35,950) 
(Reg. No. 25,647) 
(Reg. No, 34,035) 



Please address all correspondence to FARKAS & MANELLI PLLC, 2000 M Street, N.W. 
Suite 700, Washington, DC 20036-3307, and all telephone calls to William BoUman at 
(202) 261-1020, 



Full name of inventor: Richard A, Smith 




Date: ^///^^ 



Inventor's signature 

Residence: Annapolis, Anne Arundel Counti?^, Maryland 

Citizenship: USA 

Post Office Address: 12 North Southwoods Avenue, Annapolis, Maryland 21401 



